Integrated circuit (IC) technology is continuously increasing in complexity due to improvements in semiconductor process fabrication techniques. Complete system-on-chip (SoC) solutions, involving many elements such as a processor, timer, interrupt controller, bus, memory, and/or embedded software on a single circuit, are now available for a variety of applications. A challenge facing SoC designers is the efficient verification of the functionality of such systems. At process fabrication technologies of 65 nm and smaller, with millions of transistors available to implement large and complex SoCs, the challenge of functionally verifying such complex devices grows exponentially. Industry data suggests that over half of all project resources are now typically allocated to the functional verification of these devices, yet over 60% of these devices require re-engineering due to functional bugs at the initial silicon stage.
A typical design process begins with a software program that describes the behavior or functionality of a circuit to be created. Such a software program is typically written in procedural languages such as C/C++ that defines behavior to be performed with limited implementation details. RTL (Register Transfer Level) is a level at which a digital system is described in terms of synchronous transfer between functional units. RTL is one level higher than a gate level. At RTL, every operation's order of execution (and thus timing) is completely specified. An RTL model of an IC device may be used as an input to an automated digital synthesis tool to create a gate level netlist. As used herein, the term “model” is used to describe a unit, which may be realized in software and embodied on a computer readable storage medium that represents the behavior of a desired device in a form other than the actual device. A gate level netlist further goes through transistor level transformations by so-called place and route tools to reach the physical IC level.
In order to test and explore changes in the design of a SoC, simulation must be performed, which is very time consuming. A few seconds of real-time simulation at a low level such as RTL can take days or longer. If the simulation results are not desirable, then the design process must start over again by changing high-level code and re-simulating.
Because of such delays in simulation, electronic system designers are beginning to move the design process to a higher level at which there is less focus on design details. At a higher level, design exploration can be performed to evaluate achievable performance and power consumption, which parts to use, etc. A higher level that has gained popularity is called Transaction Level Modeling (TLM) or “transaction level” (TL) as used herein, which refers to a high level for modeling digital systems where communication between modules is separated from the details of the implementation of functional units. The term “transaction” refers to an electronic representation that encodes a complete interaction, e.g., writing one or more bytes from CPU to memory. A transaction may be a sequence of instructions at a higher level than the basic, atomic level at which a device operates. A transaction at RTL typically requires multiple clock cycles to execute. A TL model can quickly calculate the end result of a transaction (e.g., the end state of a device being modeled) without the need to perform each step that the real device would actually perform. A transaction at TL level may take zero time or take some “approximated” time not measured in clock cycles. In contrast, RTL level transactions are considered to take up clock cycles. Thus, a TL model executes more quickly than a lower level (and thus more faithful) model, such as an RTL model. Although TL and RTL models are described herein, other higher level and lower level models are applicable as well, with the general truism that low level models produce results slower than high level models.
A testbench may be used in the verification of system blocks (e.g., components of a circuit, or an entire SoC) using transaction models. A testbench is a software application that applies a set of stimuli (e.g., one or more test vectors) to a model to produce a set of information (responses) used in analyzing the functionality or performance (e.g., timing) of a system block. Developing testbenches at the RTL level is time consuming due to the cycle accurate nature of RTL (e.g., specifying timing faithfully in terms of cycles). RTL testbench development is also error prone due to signal level accuracy considerations. Creating a testbench at the transaction level (TL) speeds up development time, simulation time, and debug time. However, one has to recode and redevelop the TL stimulus generation and response checking mechanisms and algorithms for RTL verification, negating any speedup obtained by operating at TL.